One of the most powerful features of the server, provisioning rules determine under what conditions tokens are automatically issued and revoked. Combine provisioning rules with pre-authentication rules to seamlessly migrate users from static passwords to token authentication without service interruption and with little to no administration.

Rules are triggered when group memberships and other user attributes change. For example, if a user is added to a group that is included in a rule, STA provisions the user with a token. Conversely, if a user is removed from a group included in the rule, STA revokes the token.

Provisioning rules can be used with internal groups or with LDAP synchronized groups. By combining provisioning rules with LDAP synchronization or integration, the server can automatically issue and revoke tokens based on changes made in LDAP without the intervention of an operator.

Users in these groups must have an email address or a mobile/SMS number (depending on the token type). Otherwise, STA cannot auto-provision them with a token.

Add a provisioning rule

1. On the STA Token Management console, select Policy > Automation Policies > Provisioning Rules.

2. Click New Rule.

   

3. Configure the provisioning rule options:

   • Rule Name—This is a unique, descriptive name for the rule.

   • Token Type—This is the type of token to be provisioned when the rule evaluates true.

   • Issue Duplicate Types—If unchecked, a user is not provisioned with the selected token type if they already have one of the same type, as a result of being manually assigned a token or a different provisioning rule.

   • Auto Revoke—If checked, the token issued by this rule is revoked if the rule evaluates false for the user, such as when a user is removed from the monitored groups.

     Select this option only when a user remains synced to STA but the provisioning rule no longer applies. If a user is removed from STA (for example because they are no longer part of a sync group) all of their tokens are revoked regardless of whether Auto Revoke is selected.

   • Notify Users With Active Provisioning Revoke—If checked, users are notified if their auto-provisioned tokens are revoked by the provisioning rule.

   • Container—The user must reside in the selected container for the rule to evaluate true.

   • Require Expiring—Select this option to provision a replacement token N days before the expiration date of any assigned tokens. If you also select Auto Revoke, then the replaced token is revoked after the user enrolls the replacement token.

   • Require In-Service Expiry—This option is used to replace tokens that have been in the field for an extended period of time and are likely to need battery replacement. Enable this option to provision a replacement token for any assigned tokens that has been in use for more than N years. Enabling Auto Revoke results in the replaced token being revoked immediately upon the user completing enrollment of the replacement token.

   • Target Groups—The groups to which the rule applies.

   • Affected Group Members

     • Users that belong to ANY of the target groups. (OR Logic. Highly Recommended.)

       If one or more groups are selected for a rule, users that belong to any of the selected groups will be included in the rule.

     • Users that belong to ALL of the target groups. (AND Logic. Use with Caution.)

       

       If multiple groups are selected for a rule, only the users that belong to all of the selected groups will be included in the rule. For example, if GroupA, GroupB, and GroupC are selected, only users that belong to GroupA, AND GroupB, AND GroupC will be included in the rule.

About affected group members

Consider the case where you create provisioning rule One for Group A. Initially, the rule applies to all users in that group. However, that may change if you add a group to the original rule, depending upon whether you apply OR logic or AND logic, as described in the scenarios that follow.

If you add a group to an existing provisioning rule, you may dramatically and unexpectedly change the effect of the rule. For example, if you add a group to an AND logic provisioning rule that has provisioned tokens and has Auto Revoke selected, then tokens are revoked from all users from the original groups that are not also members of the new group.

Scenario 1: Users that belong to ANY of the target groups. (OR logic. Highly recommended.)

If you select Users that belong to ANY of the target groups and apply rule One to Group B (that is, add Group B to rule One) the rule applies to ALL users from Group A and Group B, as shown in the following table:

Group	Users	Comment
A	Alfred, Betty, Carson, Diane, Emil, Fred	After you add Group B to rule One, the users to which the rule applies is expanded to include Cory, Debbie, and Ernest (the users who belong to ANY of the groups listed in the rule). If Auto Revoke is a condition of the rule, none of the users from Groups A and B have their tokens revoked.
B	Betty, Cory, Debbie, Ernest, Fred

Scenario 2: Users that belong to ALL of the target groups. (AND logic. Use with caution.)

If you select Users that belong to ALL of the target groups and apply rule One to Group B add Group B to rule One), the rule applies to only the users who belong to both Group A AND Group B, as shown in the following table (that is, Betty and Fred).

Group	Users	Comment
A	Alfred, Betty, Carson, Diane, Emil, Fred	After you add Group B to rule One, the users to which the rule applies is reduced to Betty and Fred (the only users that belong to ALL groups listed in the rule). If Auto Revoke is a condition of the rule, the users that were previously assigned tokens by rule One that don’t belong to ALL groups Alfred, Carson, Diane, and Emil) have their tokens revoked.
B	Betty, Cory, Debbie, Ernest, Fred

Apply provisioning rules to nested groups

Auto-provisioning can be enabled for users in nested groups. When enabled, provisioning rules for a parent group are applied to all of its nested groups in STA, and all users that are in the nested groups receive an email for token activation. This policy applies to user and role provisioning. SAML service provisioning applies to users in nested groups regardless of this setting.

1. On the STA Token Management console, select Policy > Automation Policies > Provisioning Policy.

   

2. Select Provisioning Rules will use nested group relations.